REMARKS 

The Applicants have carefully reviewed the Final Office Action mailed March 14, 2008 
(hereinafter "Final Office Action") and offer the following remarks. 

Initially, the Applicants wish to thank the Examiner for indicating that claims 10-14 and 
26-30 would be allowable if rewritten in independent form. As will be detailed below, claims 1 
and 17, the base claims from which claims 10-14 and 26-30 ultimately depend, are patentable 
over the cited references. Therefore, the Applicants will refrain from amending claims 10-14 
and 26-30 at this time. Nevertheless, the Applicants reserve the right to rewrite claims 10-14 and 
26-30 at a later time. 

Claims 1-4 and 17-20 were rejected under 35 U.S.C. § 102(b) as being anticipated by 
U.S. Patent No. 6,349,336 Bl to Sit et al (hereinafter "S/f ). The Applicants respectfully 
traverse the rejection. 

Prior to addressing the rejection, the Applicants provide herewith a brief summary of the 
present invention. The present invention provides a method and system for providing a 
computer running a Web browser with HTTP access to a peer server located behind a firewall in 
a peer-to-peer network. Particularly, a peer server multiplexes Web traffic between a firewall- 
protected peer server and a peer server that is not protected by the firewall. According to the 
present invention, in response to a proxy server receiving an HTTP request to access the peer 
server located behind the firewall from the web browser, the HTTP request is translated into a 
request packet and the request packet is sent to the peer server. In response to the peer server 
behind the firewall receiving the request packet, the peer server translates the request packet 
back into the HTTP request and then responds to the request, thereby enabling generic web 
traffic to flow. The Applicants submit that Sit does not disclose the features of translating a 
HTTP request into a request packet and sending the request packet to a peer server. 

Now turning to the rejection, according to Chapter 21 3 1 of the M.P.E.P., in order to 
anticipate a claim under 35 U.S.C. § 102, "the reference must teach every element of the claim. 9 * 
The Applicants submit that Sit does not teach every element recited in claims 1-4 and 1 7-20. 
More specifically, claim 1 recites a method for providing a Web browser running on a computer 
with access to a peer server located behind a firewall comprising, among other features, in 
response to a proxy server receiving an HTTP request to access the peer server from the Web 
browser, 'translating the HTTP request into a request packet and sending the request packet to 



2 



the peer server." Claim 17 includes similar features. The Applicants submit that Sit does not 
disclose translating a HTTP request into a request packet and sending the request packet to a peer 
server, which is located behind a firewall. Instead, Sit discloses fooling a firewall in order to 
pass data to a browser, which is behind the firewall More specifically, Sit discloses wrapping a 
request sent from a browser 3 14E to a web server 3081, which is behind a firewall 305, such that, 
to the firewall 305, the request appears as a response from the browser 3 14E to a request sent by 
the web server 3081. (See Sit, col. 7, 11. 50-57). As is well known, wrapping includes a header, 
which precedes encapsulated data and a trailer, which follows the encapsulated data such that the 
encapsulated data is not viewable to a firewall. Wrapping does not involve translating a HTTP 
request into a request packet. In fact, Sit teaches away from the present invention in that Sit 
discloses fooling a firewall into allowing the transmission of a packet by altering header 
information such that the packet appears as something it is not, i.e., instead of being a request, 
the packet appears as a response. 

The Patent Office responds to this argument by stating that "the term 'translating the 
HTTP request into a request packet' under the broadest reasonable interpretation standard does 
not appear to be limiting in the sense as argued by the applicant." 1 The Patent Office goes on to 
state that the plain meaning of the term '"translating" is a step to change into another form and the 
plain meaning of the term "request packet" is any packet including a request by a sender to a 
destination. 2 Thus, according to the Patent Office, a translation of a HTTP request into a request 
packet is any modification to a HTTP request into a packet, where the packet is changed into 
another form and includes a request from a sender to a destination. 3 The Patent Office goes on to 
state that this interpretation is consistent with paragraph [021] of the Specification. 4 The 
Applicants respectfully disagree for a number of reasons. First, in the interpretation noted above, 
the Patent Office has ignored all the features recited in claim 1 . Specifically, the Patent Office is 
ignoring the feature of translating a HTTP request into a request packet and sending the request 
packet to a peer server, which is located behind a firewall. By stating "a translation of a HTTP 
request into a request packet is any modification to a HTTP request into a packet, where the 
packet is changed into another form, and where the packet includes a request from a sender to a 

1 See Final Office Action, page 2. 

2 See Final Office Action, page 2. 

3 See Final Office Action, page 3. 

4 See Final Office Action, page 3. 
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destination," the Patent Office ignores the features of a request packet and sending a request 
packet. 5 As mentioned above, according to Chapter 21 3 1 of the M.P.E.P., in order to anticipate a 
claim under 35 U.S.C. § 102, "the reference must teach every element of the claim." By 
ignoring the feature of a request packet recited in the claims, the Patent Office is ignoring its 
burden under 35 U.S.C. § 102. 

Second, the Patent Office attempts to mask this shortcoming by stating that the 
interpretation given above is consistent with paragraph [021] of the Specification, However, the 
Applicants submit that the Patent Office is impermissibly broadly construing the features recited 
in claim 1. According to Chapter 21 1 1 of the MP.E.P., while claims should be given their 
broadest reasonable interpretation, the interpretation must be "consistent with the specification." 
The Applicant submits that the Patent Office is not interpreting claim 1 in a manner that is 
consistent with the Specification. In particular, paragraph [021] of the Specification states the 
following: 

[021] FIG. 3 is a flow diagram illustrating the process for enabling a Web 
browser 30 to access the peer server 24' behind a firewall 34. The process begins 
in step 50 with the peer server 24 registering an outbound socket connection with 
the proxy server 36. In step 52, all incoming HTTP requests intended for the peer 
server 24 1 are redirected to the proxy server 36. In response to receiving a 
redirected HTTP request in step 54, the proxy server 36 finds the socket 
connection to the peer server 24', translates the HTTP requests into a multiplexed 
protocol comprising a request packet and sends the request packet to the peer 
server 24'. In step 56, the peer node 26 receives the request packet, demultiplexes 
the request, converts the request packet back into the original HTTP request, and 
passes the HTTP request to the local Web server 28. In step 58, the peer node 26 
receives an HTTP response from Web server 28, converts the HTTP response into 
a response packet, and sends the response packet to the proxy server 36 over the 
outbound socket connection. In step 60, the proxy server 36 receives the response 
packet from the peer server 24 ! , converts the response packet back into the HTTP 
response, and sends the HTTP response to the requesting web browser 30 
(emphasis added). 

As shown above, paragraph [021] states that the HTTP request is translated into a 
multiplexed protocol comprising a request packet and sends the request packet to a peer server. 
Thus, the Specification explicitly states that HTTP request is translated into a request packet, not 
just a packet. Therefore, the Applicants submit that the Patent Office is interpreting the feature 
of, in response to a proxy server receiving a HTTP request to access the peer server from the 



5 See Final Office Action, page 3. 
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Web browser, 'translating the HTTP request into a request packet and sending the request packet 
to the peer server" in a manner entirely inconsistent with the Specification. 

Third, even assuming arguendo, that the Patent Office's interpretation of the feature of 
translating a HTTP request into a request packet and sending the request packet to a peer server, 
which is located behind a firewall, was somehow correct, Sit still does not disclose all the 
features of claim 1, as interpreted by the Patent Office. Specifically, the Patent Office has 
acknowledged that the claim involves changing the packet into another form. Sit does not 
disclose this feature. As mentioned above, Sit involves wrapping a request with a header and a 
trailer. However, the packet itself is not transformed, or even changed, to use the nomenclature 
proposed by the Patent Office. For this reason and the reasons noted above, claims 1 and 17 are 
patentable over the cited reference. Likewise, claims 2-4, and 18-20, which respectively depend 
from claims 1 and 17, are patentable for at least the same reasons along with the novel features 
recited therein. 

Claims 5-7, 15, 16, 21-23, and 31-34 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Sit. The Applicants respectfully traverse the rejection. According to Chapter 
2143.03 of the M.P.E.P., in order to "establish prima facie obviousness of a claimed invention, 
all the claim limitations must be taught or suggested by the prior art." The Applicants submit 
that Sit does not disclose all the features recited in claims 5-7, 15, 16, 21-23, and 31-34. As 
detailed above, Sit does not disclose all the features recited in claim 1 or 17, the base claims from 
which claims 5-7, 15, 16, 21-23, 31, and 32 ultimately depend. Therefore, these claims are 
patentable over Sit for at least the same reasons noted above with respect to claims 1 and 17, and 
the Applicants request that the rejection be withdrawn. 

Claim 33 recites a method for providing a web browser comprising, among other 
features, in response to a proxy server receiving a redirected HTTP request, "translating the 
HTTP requests into a multiplexed protocol comprising a request packet, and sending the request 
packet to the peer server" and in response to a peer node receiving a HTTP response from the 
Web server, "translating the HTTP response into a response packet, and sending the response 
packet to the proxy server." Claim 34 includes similar features. As detailed above, 5/7 does not 
disclose translating a HTTP request into a request packet and sending the request packet to a peer 
server, which is located behind a firewall. Similarly, the Applicants have reviewed Sit and 
submit that Sit does not disclose translating a HTTP packet into a response packet and sending 
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the response packet to a proxy server. As such, claims 33 and 34 are patentable over Sit and the 
Applicants request that the rejection be withdrawn. 

Claims 8, 9, 24, and 25 were rejected under 35 ILS.C. § 103(a) as being unpatentable 
over Sit in view of U.S. Patent No. 6,917,965 B2 to Gupta et al (hereinafter "Gupta"). The 
Applicants respectfully traverse the rejection. The Applicants submit that neither Sit nor Gupta, 
either alone or in combination, discloses or suggests all the features recited in claims 8, 9, 24, 
and 25. As detailed above, Sit does not disclose all the features recited in claim 1 or 17, the base 
claims from which claims 8, 9, 24, and 25 ultimately depend. Moreover, Gupta does not 
overcome the previously noted shortcomings of Sit. Therefore, claims 8, 9, 24, and 25 are 
patentable over the cited references for at least the same reasons noted above with respect to 
claims 1 and 17, and the Applicants request that the rejection be withdrawn. 

The present application is now in a condition for allowance and such action is 
respectfully requested. The Examiner is encouraged to contact the Applicants' representative 
regarding any remaining issues in an effort to expedite allowance and issuance of the present 
application. 



Respectfully submitted, 
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